-----Original Message-----
Robert and others following the thread,
First a little background on extents in our production system. We created the
instance about 4 months prior to going live. As man of you know, getting down
time during the last few months is nearly impossible, so we saw and let extents
grow. In fact, by the time we went live, we had 2 objects over 450, 5 objects
over 300, about 50 objects (tables and indices) that were over 100 extents, and
we had hundreds of objects over 10 extents.
I agree to doing both planning for growth and monitoring growth. And the
earlier in your SAP implementation you do this the better - which is something
we did not do until after we created our productive instance.
We were very concerned about this situation and spoke to 3 or 4 different SAP
consultants. We got the same answer from each - objects in high extents will
have little or no performance impact. Like Sanjay mentioned, the consultants had
no specific reason for this.
I do not believe you will find an SAP employed person who will say you should
keep extents below a specific value. Also, I cannot definitively give that
advice either.
Over the months we have all our objects below 100 extents. We have not seen a
significant change in database response time. Our goal is to have all objects
below 20 extents - which is a corporate standard.
But we will not ask for extra down time to reach this goal.
Good luck trying to keep objects below 10 extents. While data is "pumped"
into the system during the weeks before going live, whatch the extents, they
will take off. This also occurs after performing a SAP version upgrade.
-----Reply Message-----
Why not do both? Planning for growth is critical. Monitoring daily can be
automated via CCMS can it not? With proper alert thresholds, a system freeze can
be thwarted long before extents reach 300 (max extents in my version of Oracle).
My question to you both is, how many extents are to many? I have heard from
consultants that SAP says that, for performance reasons 10 is the limit. I do
not understand the logic in this. Unless There is alot of fragmentation
throughout the tables, why not 50 or 100? I just completed a Client Copy and
have 4 tables in the BTABD tablespace that are over 17
extents. Is this to many? and should I lose the uptime for a reorg for 17 versus
10 extents?
I guess what I am asking is, since both of you seem to have put some thought
into this, is there a hard-and fast number when in comes to an acceptable amount
of extents? SAP seems to be overly conservative most of the time - was wondering
if anyone has good numbers?
